JUN-08-2005 16:16 FROM: 

Appl. No. 09/902,683 



6132328440 



TO: 17034152559 



P. 10^19 



REMARKS/ARGUMENTS 

3SU.S.C. 101 

In paragraph 3 of the Detailed Action, the Examiner has rejected claims 10 to 1 8 under 
35 U.S.C. 101 as being directed solely to a "data format" Claims 10 to 18 have been amended 
and are now directed to an Update message embodied in a transmission medium. As discussed 
in the MPEP 2106.IV.B.l(c), a signal claim directed to a practical application of electromagnetic 
energy is statutory regardless of its transitory nature (see O'Reilly, 56 US at 114-19; In Re 
Breslow, 616 F.2d 516, 519-21, 205 USPQ 221, 225-26 (CCPA 1980)). 

The Examiner is respectfully requested to reconsider and withdraw the 35 U.S.C. 1 0 1 
rejection of claims 10 to 18. 

35U.S.C103 

In paragraph 4 of the Detailed Action, the Examiner has rejected claims 1 to 6, 9 to 15, 
and 1 8 to 21 under 35 U.S.C. 103(a) as being unpatentable over the RFC 2547 document entitled 
"BGP/MPLS VPNs" (Rosen et al.) in view of the RFC 2685 document entitled "Virtual Private 
Network Identifier" (Fox et al). 

Given below is a brief description of the Rosen et al. and Fox et al references followed 
by a detailed discussion as to why claims 1 to 6, 9 to 15, and 18 to 21 are patentable over the 
Rosen et al. and Fox et al. references. 

Rosen et al. 

The Rosen et al. reference discloses a method by which a Service Provider with an IP 
backbone may provide VPNs (Virtual Private Networks) for its customers. MPLS 
(Multiprotocol Label Switching) is used for forwarding packets over the backbone and a BGP 
(Border Gateway Protocol) is used for distributing routes over the backbone. In particular, a PE 
(Provider Edge) router advertises a subscriber IP address/prefix tagged with a particular 
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community of interest identifier to all PE nodes within its domain. When a node receives an 
advertisement it checks to see if any of its subscribers have registered any interest in the 
community. If interest has been expressed, the information contained in the advertisement, a 
next-hop PE address, the subscriber IP address/prefix, and an MPLS tunnel label associated with 
the subscriber IP address/prefix is given to the interested subscriber. Unlike what is 
contemplated on page 3, line 33 and page 4, lines 1 and 2 of the present application the Rosen et 
aL reference does not disclose an information distribution scheme which allows different 
networking systems to be used by each VPN and by the backbone. In the Rosen et aL reference 
the VPNs use the same protocol as that of the backbone, and the system of the Rosen et ah 
reference provides an TP VPN service only. In particular, in this reference the advertisements 
carry insufficient information to permit the combining of different VPN types, such as APM and 
IP for example. The Rosen el aL model would have to be redesigned to permit different VPN 
types. 

Fox et aL 

The Fox et aL reference discloses the need for a Global VPN Identifier For example, as 
discussed on page 1 , paragraphs 7 to 1 0 of the Fox et aL reference, "Because a VPN is private, it 
may use a private address space which may overlap with the address space of another VPN or the 
Public Internet" and 'an IP address only has meaning within the VPN in which it exists. For this 
reason, it is necessary to identify the VPN in which a particular IP address lias meaning, "scope 
of the IP address"'. With respect, this reference discloses a Global VPN Identifier and has 
nothing to do with a BGP for distributing routes. 

Claim 1 

To begin, there are three requirements for establishing a prima facie case of obviousness: 
1) all features must be present; 2) there must be an expectation of a reasonable chance of success; 
and 3) there must be some suggestion or motivation in the prior art to combine the references. 

Claim 1 is directed to a "Border Gateway Protocol Speaker (BGP Speaker) in a 
communication system which implements at least one network based Virtual Private Network 
(KB- VPN) across a backbone, the at least one NB- VPN using an Open System Interconnect 
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(OSI) layer-2 protocol and an OSI laycr-3 protocol, at least one NB-VPN using an OS! Iayer-2 
protocol different from an OSI laycr-2 protocol used by the backbone or using an OSI layer- 3 
protocol different from an OSI layer-3 protocol used by the backbone, the BGP Speaker 
transmitting an Update message being in conformance with a Border Gateway Protocol (BGP)", 
and recites: 

"the Virtual Private Network (VPN) Membership information; 
a VPN Reachability Mode field; 
VPN Reachability information; and 
Tunnel Mechanism information". 

The Examiner has referred to page 20, paragraphs 1 to 4 of the Rosen et at. reference as 
disclosure for the "Tunnel Mechanism information" With, respect, this passage discloses how 
security tunnels are created between pairs of CE (Customer Edge) routers in a VPN. In 
particular, the passage discloses how to enable a CE router transmitting a packet to determine the 
identity of CE routers that the packet will traverse. This is done by having every route have an 
attribute which identifies the next CE router that will be traversed if that route is followed. This 
information is presented as a BGP attribute. With respect, this does not equate with "Tunnel 
Mechanism information". In particular, the identification of a next router in the Rosen et at. 
reference provides no information on the tunnel mechanism used in this reference. 

The Examiner has also conceded that the Rosen et at. reference does not disclose a 
Virtual Private Network (VPN) Membership information" nor "a VPN Reachability Mode 
field", and refers to page 1, paragraphs 5 and 7 to 10 of the Fox et al reference as disclosure for 
these claim features. With respect, what is disclosed in these passages is a Global VPN 
Identifier, and Applicant fails to see how this equates with "Virtual Private Network. (VPN) 
Membership information" and a "VPN Reachability Mode field' 1 . In particular, as discussed on 
page 10, lines 23 to 26 of the present application, a VPN Reachability Mode field is used to 
indicate the type of model being used such as a piggybacking model or a VR (Virtual Router) 
model discussed on page 3, lines 18 to 27 for example. With respect, as admitted by the 
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Examiner the Rosen etal reference does not disclose this claim feature and Applicant fails to see 
how a global VPN identifier as disclosed in the Fox et al reference equates with this feature. 

Regarding the claim feature "Virtual Private Network (VPN) Membership information", 
Applicant also fails to see how a Global VPN Identifier equates with this feature. In particular, 
although a Global VPN Identifier can be used as VPN membership information none of the cited 
references teach VPN membership information. In the Rosen et al reference an event such as 
the presence of a site within a VPN is driven by the presence of subscriber routes. If no routes 
are available for a particular site, that particular site is unknown, hi other words, in the Rosen et 
ah reference the propagation of VPN in formation is driven by the presence of subscriber routes, 
and without subscriber routes a particular VPN member is unknown within the VPN. In contrast, 
by having VPN membership information transmitted this allows members within the VPN of 
interest to be located without having to provide any information in the VPN Reachability Mode 
field. In particular, as discussed on page 9, lines 20 to 24 of the present application the VPN 
Reachability information can have zero or more VPN Reachability Entries. When there are zero 
VPN Reachability Entries the data format of the Update message can be used to provide 
membership information without having to provide or subscribe a route (VPN reachability 
information). This allows a site to be kno wn as part of a VPN irrespective of whether a route is 
available. 

None of this is taught in either of the cited references. 

As such, the claim features of claim 1 arc not all disclosed by the cited references, and 
requirement 1) for a prima facie case of obviousness cannot be satisfied. 

Regarding requirement 2), since the features of claim I are not all disclosed by the cited 
references there is no reason to believe that there is any possible combination of the teachings of 
the cited references that produces the desired result of the invention as claimed, and therefore this 
requirement cannot be satisfied. In particular, regarding the claim feature "Virtual Private 
Network (VPN) Membership information 11 , as discussed above this feature is not disclosed in the 
Rosen et al reference. Instead, this reference discloses the identification of sites as being part of 
a VPN only when a route is available and when information on the route is communicated, and 
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Applicant fails to see how the disclosure of a Global VPN identifier as disclosed in the Fox et aL 
reference can produce a VPN membership information. Regarding the "VPN Reachability Mode 
field", as discussed above, in the Rosen et aL reference all the VPNs must use the same protocol 
as the backbone and there is no VPN Reachability Mode Field. Furthermore, Applicant fails to 
see how the disclosure of a Global VPN identifier can be used to produce such a claim feature, 
and the Examiner has provided no indication of how this could be done. Similarly, regarding the 
"Tunnel Mechanism", Applicant submits that there is no disclosure in the Fox et aL reference 
that can be used in combination with the teachings of the Rosen et aL reference to produce this 
claim feature. 

As such, requirement 2) for a prima facie case of obviousness cannot be satisfied. 

Regarding requirement 3), whereas the Rosen et aL reference teaches providing VPNs 
using an IP backbone, the Fox et aL reference solves a completely different problem which has 
nothing to do with providing VPNs across an IP backbone. As such, there can be no suggestion 
or motivation to combine these references. Furthermore, in rejecting claim 1 the Examiner states 
4 it would have been obvious to use the VPN identifier field of Fox because "it is necessary to 
identify the VPN in which a particular IP address has meaning'"- Applicant respectfully 
disagrees. As can be seen from the Rosen et aL reference there is no need for such a Global VPN 
identifier as evidenced in the Rosen et aL reference, which discloses multiple VPNs without 
making use of such an identifier. Thus, requirement 3) is also not satisfied 

None of the requirements for a prima facie case of obviousness is satisfied. The 
Examiner is respectfully requested to reconsider and withdraw the 35 U.S.C. 103(a) rejection of 
claim 1 . 

Claim 2 

Claim 2 depends on claim 1 and should be allowed for the same reasons as discussed 
above with reference to claim 1. Furthermore, claim 2 recites "wherein the VPN Membership 
information includes: ... a Number of VPN-IDs field". Again, the Examiner has referred to the 
Global VPN identifier of the Fox er aL reference as disclosure for this claim feature. However, 
as discussed on page 9, lines 15 to 16 of the present application, a VPN-ID field identifies a VPN 
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to which an NLRI (Network Layer Reachability Information) relates. Although the Global VPN 
identifier can be used in a VPN-ID field there is no disclosure in any of the cited references of 
"VPN Membership information" that includes "a Number of VPN-IDs field". 

The Examiner is respectfully requested to reconsider and withdraw the 35 ILS.C. 1 03(a) 
rejection of claim 2. 

Claim 3 

Claim 3 depends on claim 1 and should be allowed for the same reasons as discussed 
above with reference to claim 1 . The Examiner is respectfully requested to reconsider and 
withdraw the 35 U.S.C. 103(a) rejection of claim 3. 

Claim 4 

Claim 4 depends indirectly on claim 1 and should be allowed for the same reasons as 
discussed above with reference to claim 1 . Furthermore, claim 4 recites the additional claim 
feature: 

"wherein a VPN Reachability Entry includes: 

a VPN Reachability Type field; 

a Length field; and 

a VPN Reachability Value field". 

In rejecting claim 4 the Examiner states "the VPN Reachability Entry is a block of bits, 
which can be segmented in anyway deemed appropriate based on the implementation, as staled 
by Fox" With respect, Applicant cannot find any such disclosure in the Fox et al, reference. In 
particular, the Fox el al. reference has nothing to do with VPN Reachability Entries. 

The Examiner is respectfully requested to reconsider and withdraw the 35 U.S.C. 103(a) 
rejection of claim 4. 

Claim 5 
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Claim 5 depends on claim 1 and should be allowed for the same reasons as discussed 
above with reference to claim L Furthermore, claim 5 further specifies the "Tunnel Mechanism 
information". However, as discussed above with reference to claim 1 there is no disclosure of 
any 'Tunnel Mechanism information" in the Fox et aL reference nor in the Rosen et aL 
reference. As such, there can be no disclosure of the additional claim feature of claim 5. 

The Examiner is respectfully requested to reconsider and withdraw the 35 U.S.C. 103(a) 
rejection of claim 5. 

Claim 6 

Claim 6 depends on claim 5 and should be allowed for the same reasons as discussed 
above wilh reference to claim 5. Furthermore, claim 6 recites the additional claim feature: 

"wherein a VPN Tunnel Enry includes: 

a Tunnel Type field; 

a Length field; and 

a Tunnel Value field". 

Again, the Examiner states "the PM Tunnel Entries [sic] is a block of bits, which can be 
segmented in anyway deemed appropriate based on the implementation, as stated by Fox". With 
respect, there is no such disclosure in the Fox et aL reference, In particular, the Fox et aL 
reference has nothing to do with a VPN Tunnel Entry* 

The Examiner is respectfully requested to reconsider and withdraw the 35 U.S.C. 103(a) 
rejection of claim 6. 

Claim 9 

Claim 9 depends on claim 1 and should be allowed for the same reasons as discussed 
above with reference to claim L Furthermore, claim 9 recites "wherein the Update message 
further includes a field indicating a topology of a NB-VPN". The Examiner has referred to page 
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1 0, paragraphs 3 to 5 of the Rosen el al reference as disclosure for this claim feature. However, 
Applicant cannot find any such disclosure in that passage. 

The Examiner is respectfully requested to reconsider and withdraw the 35 U.S.C. 103(a) 
rejection of claim 9. 

Claims 1 0 to 1 8 

In paragraph 6 of the Detailed Action, the Examiner has rejected claims 10 to 18 for the 
same reasons as the BGP Speaker claims 1 to 9 are rejected. Claims 1 0, 1 1 , 12, 13, 14 f 15, 16, 
17, and 1 8 are patentable over the cited references for the same reasons that claims 1, 2, 3, 4, 5, 
6, 7, 8, and 9, respectively, are patentable. 

The Examiner is respectfully requested to reconsider and withdraw the 35 U.S.C. 103(a) 
rejection of claims 10 to 18. 

In paragraph 7 of the Detailed Action, the Examiner has rejected claims 1 9 to 2 1 for the 
same reasons that the BGP Speaker claims 1 to 9 were rejected. 

Claim 19 is directed to a Virtual Router (VR) and recites, among other features: 

"the Update message further including information relating to a NB-VPN to which the 
VR belongs and information relating to networking systems used by the NB-VPN to which the 
VR belongs, and the VR including instructions for establishing an OSI laycr-2 connection to at 
least one other VR in the communication system". 

With respect, the Examiner has not addressed this claim feature of claim 19, and 
Applicant submits that this claim feature is not disclosed in any of the cited references. As such, 
requirement 1 ) for a prima facie case of obviousness cannot be satisfied. Furthermore, since 
these features are not disclosed in any of the cited references there is no reason to believe that the 
teachings of the cited references can be combined to produce the desired result of the invention 
as claimed in claim 19, and requirement 2) for a prima facie case of obviousness cannot be 
satisfied. Finally, as discussed above the Rosen el al. and Fox et al. references teach completely 
different solutions to different problems, and there is no suggestion or motivation to combine 
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these references. As such, requirement 3) for a prima facie case of obviousness cannot be 
satisfied, 

Thus, none of the requirements for a prima facie case of obviousness are satisfied. 

The Examiner is respectfully requested to reconsider and withdraw the rejection of claim 

19. 

Claim 20 

Claim 20 depends on claim 19 and should be allowed for the same reasons as discussed 
above with reference to claim 19. Furthermore, claim 20 should be allowed for the same reasons 
as discussed above with reference to claim 1. 

The Examiner is respectfully requested to reconsider and withdraw the rejection of 
claim 20. 

Claim 21 

Claim 21 depends on claim 20 and should be allowed for the same reasons as discussed 
above with reference to claim 20. Furthermore, claim 21 should be allowed for the same reasons 
as discussed above with reference to claim 9. 

In paragraph 5 of the Detailed Action, the Examiner has rejected claims 7, 8, 16, and 17 
under 35 U.S.C. 103(a) as being unpatentable over the Rosen et aL reference in view of the Fox 
et aL reference, and further in view of the RFC 2283 document entitled "Multiprotocol 
Extensions for BGP-4" (Bates et al.). 

Claims 7. 8. 16. and 17 

Each one of claims 7, 8, 16, and 17 depends directly or indirectly on one of base claims 1 
and 10 and should be allowed for the same reasons as discussed above with reference to base 
claims 1 and 10. In particular, the Rosen et al. and Fox et aL references fail to disclose all of the 
claim features of base claims 1 and 10, and Applicants submits that the Bates el aL reference also 
fails to disclose the claim features of base claims 1 and 10 that the Rosen et ah and Fox et aL 
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references fail to disclose. 

The Examiner is respectfully requested to reconsider and withdraw the 35 U.S.C. 103(a) 
rejection of claims 7 and 8, 

In view of the foregoing, early favorable consideration of this application is earnestly 
solicited. 



Respectfully submitted, 



HAMD OULD BRAHIM, ET AL 




Jaities McGraw 
Reg. No. 28,168 



Date: June 8, 2005 
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